In the area of data communications networking, among others, hardware implementations are often subject to large scale changes late in the design cycle, putting extreme stress and shock on the methodology and implementation processes. Further, due to constantly evolving standards, such changes may occur more than once and if ignored or not acted upon, the entire design can be rendered incompatible with and unable to inter-work with other vendors' hardware.
Networking is one area in the design of hardware where each vendor's equipment, albeit proprietary, must be able to inter-work with other vendors' equipment. Due to this need, numerous standards bodies and forums exist where representatives of the vendors at the box, chip and wire level meet and devise manifold protocols. Due to the involvement of multiple vendors, often with competing needs, the protocol and specification development process is a long and tedious one with changes happening very often. Therefore there is a need for a mechanism that is readily adaptable to such changes while isolating the core design from these changes.
One aspect of a data communications network that is commonly subject to such changes is the format of data packets carried thereon. The packet format is the format in which a payload is packed at a transmitter so that it can be properly decoded, identified and acted upon by a receiver. Based on the packet format, several key decisions vis-a-vis the packets are taken including but not restricted to the forwarding of the packet back to the network, the termination of the packet to the host or discard of the packet.
Known ways of dealing with late changes in packet format include delaying the deployment of such changes or not implementing them at all. This leads to possible compatibility issues and is not desirable in the long run. Typically, if a decision to implement changes is made, however, the changes are usually not restricted to key points in the design, but rather are made universally. While this may be a good approach for scratch designs, for existing cores, the design shock is propagated throughout and leads to extended design and verification effort, increasing the time to market. Furthermore, due to the occurrence of changes late in the development cycle, substantial risk is undertaken to make such radical changes while ensuring that the final design is fully functional and compatible.
A related problem area has been the implementation of several different architectures for reliable communication between nodes in a Metropolitan Area Network (MAN), in which the nodes are typically distributed over an area of several hundred kilometers. Important considerations in determining which architecture to implement include availability and recovery from failure, efficient bandwidth management, and the proper arbitration of newly inserted host traffic versus the traffic already on the ring.
Two architectures are particularly pervasive in the MAN space, the Spatial Reuse Protocol (SRP) architecture and the IEEE 802.17 Resilient Packet Ring (RPR) architecture. The SRP architecture began as a vendor-specific architecture on which several hardware implementations have been made. In order to promote the technology and to make it acceptable to multiple vendors, however, the SRP architecture became the seed over which the RPR architecture was developed.
The RPR architecture substantially enhances bandwidth sharing, resiliency, and the command, control and communication aspects of Metropolitan Area Networks by introducing new packet formats and advanced protocols. As the RPR architecture developed, several changes in frame structure made it backwardly incompatible with the SRP architecture. With products already available in SRP and with the RPR standard still evolving, the need has arisen to have dual architecture support.
A known approach to implementing RPR and SRP has been to implement the two architectures in a mutually exclusive way, with the hardware supporting only one set of features. Where both architectures are supported, the implementations have typically been cumbersome, complex and error prone with the features of one architecture affecting the other architecture. In the alternative, where only one implementation is supported, the advantages of having dual architectures are lost.
Other known solutions have been to allow the two architectures to coexist but to make them traverse the same pipes. This leads to possible interference between the two architectures in terms of integrity checks and packet formatting. It also makes the design convergence cycle longer because any design shocks due to frequent changes in the evolving architecture will affect the implementation of the other more stable architecture.